Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@src/main/java/com/jobdri/jobdri_api/domain/analysis/service/AnalysisAiClient.java`:
- Around line 137-141: Update the prompt text in AnalysisAiClient to exactly
mirror the service-layer validation in
AnalysisService.isInstructionLikeImprovement(): include both verb forms like
"추가하세요" and "추가하여" (and other variants the service checks), and list the
sentence-ending patterns the service rejects (e.g., "하세요.", "해주세요.", "해야 합니다.")
so the LLM guidance and the validation logic are consistent; reference the
method AnalysisService.isInstructionLikeImprovement() when locating the exact
phrase/regex patterns to sync and modify the bullet points in the prompt block
accordingly.

In
`@src/main/java/com/jobdri/jobdri_api/domain/analysis/service/AnalysisService.java`:
- Around line 234-242: The isInstructionLikeImprovement method currently uses
brittle contains() checks that cause false positives; replace those substring
checks with stricter pattern matching (e.g., use a regex to detect
imperative/instructional sentence forms at boundaries or combine imperative
verbs with imperative endings) or invert to a whitelist of declarative endings;
specifically, modify isInstructionLikeImprovement to stop using
improvement.contains("추가하여") / "명확히 하세요" / "보완하세요" and instead use a regex that
matches instruction-like forms (imperative phrases ending with "하세요", "해주세요",
"하세요\\." etc. anchored to sentence boundaries) or validate declarative endings
such as "습니다.", "했습니다.", "됩니다." to avoid discarding valid declarative
improvements referenced by AnalysisAiClient prompt.

In
`@src/test/java/com/jobdri/jobdri_api/domain/analysis/service/AnalysisServiceTest.java`:
- Around line 239-264: Add the new test method
analyzePreservesDeclarativeImprovement (as in the suggested snippet) to
AnalysisServiceTest to assert that a legitimate declarative improvement string
is preserved; then update the isInstructionLikeImprovement(...) logic (the
method currently using contains("추가하여") and similar checks) to be more
discriminating—e.g., detect imperative forms or explicit instruction markers
(use regex that matches sentences starting with imperative verbs or ending with
imperative/formal instruction endings like "하세요", "해라", "해주세요") instead of
blanket contains checks—so declarative sentences such as the provided
validImprovement are not normalized to empty.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In
`@src/main/java/com/jobdri/jobdri_api/domain/analysis/service/AnalysisService.java`:
- Around line 235-241: The current imperative-detection expression in
AnalysisService (the return statement that checks improvement.endsWith(...) and
improvement.matches(...)) misses spaced variants like "해 주세요" or "해 주십시오";
update those checks to accept optional whitespace between "하" and the following
honorific/ending. Specifically, add endsWith("해 주세요.") and endsWith("해 주십시오.")
(or use a single endsWith check with normalized whitespace), and change the
regex fragments "하(세요|십시오)" and "하(세요|야 합니다)" to allow optional spaces (e.g.,
"하\\s*(세요|십시오)" and "하\\s*(세요|야 합니다)"), and similarly update any other matches
that assume no space so the method in AnalysisService correctly flags both
joined and spaced imperative forms.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@src/main/java/com/jobdri/jobdri_api/domain/analysis/service/AnalysisService.java`:
- Around line 237-242: The current normalization/filtering logic in
AnalysisService.java for the variable improvement misses imperative variants
ending with "하십시오" and "해주십시오", so phrases like "문장을 명확히 하십시오." or "수정해주십시오."
bypass the filter; update the conditional that checks improvement (the branch
with improvement.endsWith(...) and improvement.matches(...)) to include explicit
checks for "하십시오" and "해주십시오" variants and extend the regex patterns (e.g., the
matches that handle "해 주십시오", "해주십시오", and "하십시오" forms) so those imperative
forms are normalized/filtered the same as existing "해 주세요"/"해 주십시오"/"해야 합니다"
cases.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@src/main/java/com/jobdri/jobdri_api/domain/analysis/service/AnalysisService.java`:
- Line 245: The current improvement.matches(...) call in AnalysisService.java
forces a trailing period via "\\.$", causing imperative commands without
punctuation (e.g., "수정해주십시오") to bypass the filter; update the regex used in the
improvement.matches(...) expression so the final period is optional (for example
by using "(\\.|$)" or making the final "\\." optional) so both forms with and
without a trailing dot match; adjust only the regex string in the
improvement.matches(...) invocation to enforce this change.